In many computing systems, software modules may be executed “in-place”, otherwise known as XIP, for reasons of speed and memory conservation. Most types of embedded devices do not have secondary storage such as a hard disk. Therefore, software modules may be stored in non-volatile primary memory such as read-only memory (ROM) or flash memory. In classical environments such as non XIP-enabled embedded environments, a software module may be copied from a storage location to system random-access memory (RAM) before being executed. In XIP enabled environments, software modules may be executed directly from where they are stored if certain conditions are met.
With XIP technology, software modules typically may be stored in primary memory such as ROM or flash memory. These types of memories may be directly accessible by an execution unit of a central processing unit (CPU) or processor. Another requirement may be that the software modules have fully resolved memory references. Executing a software module in an XIP mode may lead to improved performance when launching the module. Another aspect of XIP is that the device may utilize less RAM space since software modules may be executed directly from ROM or flash memory.
When a software module is configured for XIP, the module may be required to be stored in a “ready to run” state. As a result, typical schemes of storing software modules as a compressed image in ROM or flash memory are generally not suitable for XIP. In general, modules configured for XIP may take up more space in ROM or flash than non-XIP modules that are compressed for storage. As a result, there is a memory size related conflict between XIP and non-XIP schemes. Whereas in non-XIP schemes, compressing the stored module may conserver read-only memory (ROM) or flash memory, the non-XIP schemes may require more RAM to execute the modules as a result. On the other hand, in an XIP scheme, using XIP reduces the need for RAM, however relatively larger ROM or flash memory may be required since software modules need to be stored in a non-compressed mode.
For the above reasons, in a typical device capable of supporting an XIP mode, some software modules are XIP enabled, and other modules are non-XIP enabled. The decision whether a module is XIP or non-XIP typically may be made at the device build-time. After the device is built and deployed, the software modules generally cannot be switched between XIP and non-XIP modes.
It will be appreciated that for simplicity and clarity of illustration, elements illustrated in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements are exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals have been repeated among the figures to indicate corresponding or analogous elements.